LAYER 1: EXECUTIVE CONTEXT (Cody's Notes)

LAYER 2: CORE PHILOSOPHY (The Narrative Summary)

The DORA (DevOps Research and Assessment) metrics represent the industry-standard framework for measuring and optimizing software delivery performance. Originally established through a decade of rigorous academic research led by Dr. Nicole Forsgren and Google, DORA shifts the paradigm of technology management from measuring individual developer activity (which is easily gamed and counterproductive) to assessing the systemic health, throughput, and stability of the entire software delivery engine.

For a product and technology organization transitioning from a "feature factory" to "empowered product teams," DORA metrics serve as a vital diagnostic tool. They establish a clear baseline for engineering velocity and operational quality, allowing VPs and AVPs to identify bottlenecks in the deployment pipeline. By focusing on these four metrics—Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Failed Deployment Recovery Time—technical leaders can ensure their teams are reducing friction, maximizing automated feedback loops, and delivering continuous business value safely.

The Throughput vs. Stability Tension

A key insight of the DORA framework is that speed and stability are not mutually exclusive; they are reinforcing. High-performing engineering organizations do not trade off quality for velocity. Instead, they leverage techniques like continuous integration, test automation, trunk-based development, and small batch sizes to achieve both.

1. Throughput (Velocity): Measured by Deployment Frequency and Lead Time for Changes. This captures how quickly a developer's idea or commit can reach production.
2. Stability (Quality): Measured by Change Failure Rate and Failed Deployment Recovery Time. This captures how often releases cause impairment and how quickly the system recovers.

Connective Tissue: Systemic Velocity & DevEx (Pillar 1)

Within the Technology Operating Model (TOM), DORA is the empirical foundation of Get Stuff Done (Pillar 1). A high-performing deployment engine is a prerequisite for a strong Developer Experience (DevEx). When deployment pipelines are slow, manual, or highly prone to failure, developer cognitive load skyrockets, feedback loops are delayed, and delivery velocity stalls. By actively monitoring and improving DORA metrics, technology leaders directly reduce operational friction, enabling engineers to maintain focus and flow.

LAYER 3: FULL REFERENCE (Raw Article Content)

DORA’s Software Delivery Performance Metrics

Discover the essential measurements that can inform your ongoing journey of continuous improvement.

by Nathen Harvey

Technology-driven teams need ways to measure performance so that they can assess how they’re doing today, prioritize improvements, and validate their progress. DORA has identified five software delivery performance metrics that provide an effective way of measuring the outcomes of the software delivery process. DORA’s research shows that these performance metrics predict better organizational performance and well-being for team members.

A history of DORA's software delivery metrics

These metrics have evolved alongside the technology landscape: shifting from the original four keys to the current five-metric model. To understand the research behind changes like the move from MTTR to Failed Deployment Recovery Time, read A history of DORA’s software delivery metrics.

These software delivery performance metrics can be viewed as both leading and lagging indicators. Leading indicators typically signal potential future changes in a system while lagging indicators reflect past performance and outcomes.

Throughput and instability[](https://dora.dev/guides/dora-metrics/#throughput-and-instability)

DORA’s software delivery performance metrics focus on a team’s ability to deliver software safely, quickly, and efficiently. They can be divided into metrics that show the throughput of software changes, and metrics that show instability of software changes.

Throughput[](https://dora.dev/guides/dora-metrics/#throughput)

Throughput is a measure of how many changes can move through the system over a period of time. Higher throughput means that the system can move more changes through to the production environment. DORA uses three factors to measure software delivery throughput:

• Change lead time: The amount of time it takes for a change to go from committed to version control to deployed in production.
• Deployment frequency: The number of deployments over a given period or the time between deployments.
• Failed deployment recovery time: The time it takes to recover from a deployment that fails and requires immediate intervention.

Instability[](https://dora.dev/guides/dora-metrics/#instability)

Instability is a measure of how well the software deployments go. When deployments go well, teams can confidently push more changes into production and users are less likely to experience issues with the application immediately following a deployment. DORA uses two factors to measure software delivery instability:

• Change fail rate: The ratio of deployments that require immediate intervention following a deployment. Likely resulting in a rollback of the changes or a “hotfix” to quickly remediate any issues.
• Deployment rework rate: The ratio of deployments that are unplanned but happen as a result of an incident in production.

Taken together, these two factors for software delivery performance (throughput and instability) give teams a high-level understanding of their software delivery performance. Measuring these over time provides insight into how software delivery performance is changing. These factors can be used to measure any application or service, regardless of the technology stack, the complexity of the deployment processes, or its end users.

Key insights[](https://dora.dev/guides/dora-metrics/#key-insights)

DORA’s research has repeatedly demonstrated that speed and stability are not tradeoffs. In fact, we see that the metrics are correlated for most teams. Top performers do well across all five metrics, and low performers do poorly.

These metrics work for any type of technology your organization is delivering, but are best suited for measuring one application or service at a time. Whether you are building large language models, retail banking applications, mobile food ordering applications, or mainframe-based travel systems, these five metrics can help you assess the delivery performance of your application.

Context matters. Apply the metrics in the context of the application or service your team is delivering. The context for your application, organization, and users will vary from other applications that your organization is delivering. While it may be tempting to blend metrics across multiple teams–or entire organizations–these differences in context mean that doing so can be problematic.

Common pitfalls[](https://dora.dev/guides/dora-metrics/#common-pitfalls)

There are some pitfalls to watch out for as your team adopts DORA’s software delivery metrics, including the following:

• Setting metrics as a goal. Ignoring Goodhart’s law and making broad statements like, “Every application must deploy multiple times per day by year’s end,” increases the likelihood that teams will try to game the metrics.
• Having one metric to rule them all. Attempting to measure complex systems with the idea that only one metric matters. Teams should identify multiple metrics, including some with a healthy amount of tension between them. Choose a measurement framework to fit your organizational goals.
• Using industry as a shield against improving. For example, some teams in highly regulated industries might claim that compliance requirements prevent them from disrupting the status quo.
• Making disparate comparisons. These metrics are meant to be applied at the application or service level. Comparing metrics between vastly different applications (for example, a mobile app and a mainframe system) can be misleading.
• Having siloed ownership. Sharing all five metrics across development, operations, and release teams fosters collaboration and shared ownership of the delivery process. Isolating teams with specific metrics can lead to friction and finger-pointing.
• Competing. The goal is to improve your team’s performance over time, not to compete against other teams or organizations. Use the metrics as a guide for identifying areas for growth and celebrating progress.
• Focusing on measurement at the expense of improvement. The data your team needs to collect for the software delivery metrics is available in a number of different places today. Building integrations to multiple systems to get precise data about your software delivery performance might not be worth the initial investment. Instead, it might be better to start with having conversations, taking the DORA Quick Check, or using a source-available or commercial product that comes with pre-built integrations.

What pitfalls have you encountered? Share your own cautionary tales with the DORA community by posting to the mailing list at https://dora.community.

Dive into the research[](https://dora.dev/guides/dora-metrics/#dive-into-the-research)

DORA’s research goes beyond these five metrics, exploring various capabilities that contribute to high performance. You can learn more about these capabilities and their impact on software delivery by visiting the capability catalog.

By understanding and effectively utilizing DORA metrics, you can gain valuable insights into your software delivery performance and drive continuous improvement. Remember, the goal is to deliver better software faster, and DORA metrics provide the compass to orient teams toward that objective.

Next steps[](https://dora.dev/guides/dora-metrics/#next-steps)

A common approach to improving the five key metrics discussed in this guide is reducing the batch size of changes for an application. Smaller changes are easier to rationalize and to move through the delivery process. Smaller changes are also easier to recover from if there’s a failure. Teams should make each change as small as possible to make the delivery process fast and stable. Working in this way contributes to both change throughput and change stability.

We have found that an effective way of making changes is to gather the cross-functional team that is responsible for prioritizing, building, delivering, and operating an application for a discussion about improving their software delivery performance. Once the team is gathered, walk through the following steps:

• Set a baseline for your application’s current performance using the DORA Quick Check.
• Have a conversation about the friction points in the delivery process. Mapping out the delivery process may help facilitate this part of the process.
• Have the whole team commit to making an improvement in the most significant constraint or bottleneck.
• Turn that commitment into a plan, which may include some more specific measures that can serve as leading indicators for the software delivery metrics. For example, you may decide to measure how long code reviews take or the quality of your tests.
• Do the work. There are very few shortcuts, to make progress your team may need to change the way they work.
• Check your progress. Use the DORA Quick Check, conversations, and team retrospectives to validate the progress you’ve made.
• Repeat the process as a way to continue the learning and improvement.

Generated for the Product Growth Program.